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Aether Systems 



Field of Invention 

The present invention relates in general to the field of communications and in 
particular to a method and system for deploying content to devices. 

5 Background of the Invention 

A multitude of wireless handsets, personal data assistants (PDAs), and pagers 
exist that feature microbrowsers for wireless access to the World Wide Web (Web). 
Wireless Web development standards are emerging from groups such as the Wireless 
Access Protocol (WAP) Forum™. However, these standards have yet to fully permeate 

10 the market. Therefore, handset and PDA manufacturers currently support several 
different protocols and markup languages. The plethora of protocols and languages create 
a problem for application developers trying to provide content that can be presented, with 
some consistency, across the widest range of devices. This is often referred to as the 
"Write Once, Render Anywhere" problem. The WAP Forum is addressing this problem 

15 by standardizing on a markup language, Wireless Markup Language (WML), and 
providing a set of guidelines for developers. Although a tremendous help, WML does not 
cover the vast array of devices already on the market, not to mention those devices 
deployed with non-conformant software and services. 

Most wireless Web enabled devices attach to a gateway or proxy system housed 

20 at a network carrier or Wireless Service Provider (WSP). Figure 1 shows various 
methods of wireless Internet access. Most Web enabled phones 2 use the phone.com 3.x 
UP.Browser to request content from an origin Web server. Phone.com UP.Link gateways 
3, housed at the carrier sites, process these requests, which are fulfilled over the Internet 4 
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via services 5. Newer phones and some pagers already support the WAP standards and 
they connect through a WAP gateway 6. Web-enabled Palm PDAs 7 pass through a 
proxy service 9, 10, which is supplied by Palm.net or OmniSky services, for example. 
All of these methods are similar, in that the wireless request passes through a gateway or 

5 proxy service, for example, UP.Link gateway 3, WAP gateway 6, and proxies 9, 10, to be 
translated into a wire-based HTTP/S request. Although the request model for the most 
common wireless Internet connections are similar, their underlying networks and device 
technologies differ. Wireless handset and PDA operating systems are usually delivered 
with a communication stack that abstracts the application developer from the underlying 

10 communication protocols and network technologies. Microbrowsers supplied on the 
wireless handsets and PDAs render hyperlinked markup content on the user interface 
display and enable user-directed navigation. 

Currently, custom Web applications have to be developed for each specific device 
that uses different languages and protocols. Accordingly, there is a need for a uniform 

1 5 approach to content delivery to deliver an application to the broadest audience, across the 
widest possible set of devices. 

Summary of the Invention 

A method and system for deploying content to devices is provided. The method 
20 and system can be used to deploy markup content to web browser applications on 
wireless devices. The wireless device may included, for example, WAP phones, HDML 
phones, Palm VII, Palm V, etc. The method and system can also be used in conjunction 
with wired systems. A translator receives data, in a variety of formats, from the wireless 
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devices. The translator then translates the data into a standardized format. A content 
provider interface receives the data in the standardized format and provides content data, 
also in the standardized format. The content data in the standardized format is provided 
to a transformer. The transformer transforms the content data into a format for the 
5 particular wireless device and/or application. The content data can then be utilized and 
manipulated by the wireless device. 

In another embodiment, data can be spontaneously sent to a device from a content 
provider. The data and an identifier (ID) to may be provided to the transformer. The ID 
can be looked up in a database to associate it with a device. A content type specific form 
10 is determined for the device. Based on the content type specific form, a transformation 
may be selected. The data can then be transformed using the selected transformation and 
the transformed data forwarded to the device. In a further embodiment, multiple 
transformations can be applied to the data. The transformations may be applied 
sequentially, independently, or a combination of both. The independent transformations 
1 5 may be done simultaneously. 

According to another embodiment, a method for deploying markup content to 
browser applications on devices is provided. Messages and requests are accepted from 
the devices. The messages and requests may be processed as synchronous messages via a 
block and wait mechanism. Information related to form data, session data, MIME data, 
20 and a message key can be retrieved in order to generate an XML stream. The XML 
stream may then be parsed into an XML message. Next, it can be determined which of a 
number of content provider interfaces can handle the XML message based on the 
message key. A content provider interface should be selected to process the XML 
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message and the XML message can be forwarded to the selected content provider 
interface. A response is then received from the selected content provider interface. One 
or more XSL stylesheets may be selected and used to transform the response into device 
type specific and content type specific form. Next, the transformed response can be 
forwarded to the requesting devices. 

In a further embodiment, a method for deploying markup content to browser 
applications on devices is provided. Requests are accepted from devices. The requests 
are preferably processed as synchronous messages via a block and wait mechanism. 
Information related to at least one of form data, session data, MIME data, and a message 
key is retrieved in order to generate an XML stream. The XML stream is parsed into an 
XML message. Content provider interfaces that can handle the XML message are 
determined based on the message key and a content provider interface is selected to 
process XML message. The XML message is provided to the selected content provider 
interface. A response is received from the selected content provider interface. One or 
more XSL style sheets may be selected to transform the response into one or more forms. 
The transformed response may then be sent to the requesting devices. 

Additionally, the system and method allow for content providers to be added 
dynamically. According to one possible method, an XSL style sheet should be 
previously registered in a provider database for any new content providers to be added. 
When a content provider is added dynamically, the provider database is queried. The 
previously registered XSL style sheet associated with the new content provider is 
received from the provider database. This style sheet may then be used to transform data 
provided by the new content provider. 
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Brief Description of the Drawings 

Fig. 1 shows various methods of wireless Internet access; 

Fig. 2 shows an overview of information flow in the system according to an 
embodiment of the invention; 

Fig. 3 illustrates components in an embodiment of the system; 

Fig. 4 shows the an overview of the system according to an embodiment of the 
invention; 

Fig. 5 depicts a logical component model for handling asynchronous request 
messages/responses and alerts; 

Fig. 6 depicts a physical model of a wireless web architecture according to an 
embodiment of the invention; 

Fig. 7 illustrates method interfaces to the message controller; 

Fig. 8 is a Java binding diagram; 

Fig. 9 illustrates a request transformer interface; 

Fig. 10 is an object model of the XML transformer; 

Fig. 1 1 illustrates chaining transformations; 

Fig. 12 illustrates chaining transformations for branding; 

Figs. 13a and 13b show simultaneous transformations; 

Fig. 14 illustrates a hybrid simultaneous and sequential transformation; 

Fig. 15 shows a response transformer; and 

Fig. 16 shows a CPI interface. 
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Detailed Description of the Invention 

A method and system for deploying content to devices is provided. The method 
and system can be used to deploy markup content to web browser applications on 
wireless devices. The wireless device may included, for example, WAP phones, HDML 

5 phones, Palm VII, Palm V, etc. A translator may receive data, in a variety of formats, 
from the wireless devices. The translator then translates the data into a standardized 
format. A content provider interface receives the data in the standardized format and 
provides content data, preferably also in the standardized format. The content data in the 
standardized format is then provided to a transformer. The transformer transforms the 

10 content data into a format for the particular wireless device and/or application. The 
content data can then be utilized and manipulated by the wireless device and/or 
application. 

Figure 2 illustrates an exemplary overview of the flow of information when a 
request for information is made. In step 1, a user makes a request from a wireless device. 

15 This is typically done via a Web browser either by entering a URL manually, or by 
selecting a link on a phone, PDA or other wireless device 20. The user's request passes 
through the appropriate carrier network 22 in step 2 and eventually arrives, usually as an 
HTTP/S request, at a web application server 30. The user's request may then be 
forwarded in step 3 to the system, preferably in the form of Java objects. The translation 

20 of the request into Java objects may be accomplished through the use of JSP and/or Java 
servlets. Once received by the system, the user's request is converted by the translator 41 
in step 4 into a standardized format, preferably an Extensible Markup Language 
(XML™) message, (XML is a technical specification developed by The World Wide 
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Web Consortium (W3C)). The request is also preferably validated and processed and 
then sent to a content provider interface 50 (CPI). In step 5, the CPI 50 receives the 
request in the form of a message and produces a response message, preferably in the 
standardized format. In many cases, the CPI 50 interacts with a third party service 60 to 
5 perform any business logic and retrieve the actual content. The response message is 
returned through the system and converted to the required output content type (i.e., 
HDML, WML, HTML) by step 6. The transformer may apply a transformation to 
convert the message. If the standardized format is an XML message, this is preferably 
done using XSL, a specification also developed by W3C. An appropriate XSL stylesheet 
10 is selected for the transformation preferably based on the user agent of the device and 
other appropriate information. Per step 7, the transformed response content is returned 
back to the device 20, preferably in an HTTP/S response. The device's microbrowser can 
then render the content for the user in step 8. 

In addition to communication with a CPI to respond to a request, the system and 
1 5 method can unilaterally deploy content from the content provider interface or third party 
to the device, without having received a request from the device. This is called sending 
the device an "alert" or "push". The process of sending an alert is very similar to sending 
a response and is described in more detail below. 

A component-based architecture for mid-tier services may be provided to perform 
20 the above described functions. As mentioned above, the services provided by the 
architecture are preferably written in Java and use XML as a common language of 
transference and translation, although other suitable languages can be used. XML can be 
used to define a standard set of request and response messages. Employing XML's 
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Document Type Definition (DTD) language, requests and responses used in a standard 
market setting, such as stock trading and brokerage services, can be defined. Once 
defined in a given vertical market, a DTD can be used across clients in a uniform fashion. 
Of course, other schemas can be used to specify vertical market requests and responses. 

As mentioned above, the W3C also provides a set of specifications for the 
Extensible Stylesheet Language (XSL ™). Stylesheets can house the presentation format 
for a given device display, abstracting the presentation and formatting language from the 
data content housed in the XML. XSL also supplies syntax for transforming XML 
markup content into other markup forms, and is referred to as SLT. SLT may be used to 
change the common data formats of content into the presentation languages (i.e., HDML, 
WML, HTML, etc.) required by the wireless devices. 

Turning now to fig. 3, an example of a platform deployed with the architecture is 
illustrated. The platform can include various components such as an HTTP/S server 14, a 
standard Java application server 16, and a relational database 18. Applications can be 
developed and supported by this platform. Each component should operate over objects 
referred to as "messages." Messages can simply be data containers. Each message should 
have associated header information, such as a message key (described below), which 
helps to identify the context of the message, its payload, and how it is handled. The 
payload of the message is the actual data used in a transaction, such as a quote symbol, an 
account number, or even a bill summary. Using messages helps to give each component a 
standard integration interface that facilitates reusability. In a preferred embodiment, 
messages can be delivered to the components either as Java objects or as XML. 
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As mentioned above, a message key is preferably associated with each message in 
order to facilitate the routing of information and the dispatching of requests in the system. 
The information included in a message key can vary depending on the vertical market. 
The message key should include the following information: 

1. Market Domain — The vertical market (for example, electronic payment and 
processing, banking, or financial trading) wherein the message falls. 

2. Action — Identifies, within the context of the market domain, the specific action to 
which the message data pertains (for example, quote, account transfer, etc). 

3 . Action Type — Request, response, alert or other action. 

4. Content Provider ID — Uniquely identifies a specific content provider that is to 
handle the request. In some cases, this is necessary to route the request directly to a 
given CPI. In other cases, it is not necessary to specify a content provider ID in the 
message key. 

The message key can be used to uniquely identify common requests within a specific 
vertical market. Information in the message key may be used to facilitate processing of a 
message by the system. For example, the content provider ID references a specific back- 
end system with which the user may maintain an account. The system thus knows where 
to route a request. The content provider ID may remain blank; however, the other 
elements of the message key; market domain, action, and action type, are preferably 
always specified in order to ensure the message is properly handled. 

Fig. 4 shows an example of a preferred embodiment of system that can provide a 
uniform approach to content delivery. The components and services described may be 
hardware, software, firmware, or any other reasonable form or media that accomplishes 
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the tasks at hand as described and disclosed herein. Scalability may be managed by 
enterprise-level HTTP server tools and technologies (i.e., IBM's HTTP Server and 
WebSphere). 

A plurality of various wireless devices 20 capable of Internet access communicate 

5 over a wireless communication medium 25 to a network operation center 19, which 
houses the components and services that support and process request messages, response 
messages and alerts for the wireless devices 20. Request messages, response messages 
and alerts are preferably communicated to and from wireless devices 20 via a proxy 
server and web applications 30. Proxy server and web applications 30 communicate with 

10 the wireless web architecture 40 via communication media 35 for request messages 
(inbound) and communication media 37 for response messages and alerts (outbound). 
The wireless web architecture 40 can communicate with a plurality of content provider 
interfaces 50 via communication media 45 for translated request messages and via 
communication media 48 for response messages and alerts. Content provider interfaces 

1 5 50 may communicate with third party content providers 60 via communication media 55, 
such as a wide area network (WAN) or the Internet. The third party content provider can 
provide information to generate a response message or an alert. A content provider 
interface 50 may be an object that is registered with the system to handle specific actions 
that are sent in a request message. The content provider interface 50 may provide proxy 

20 services to the third party content providers or it may fully encompass the content 
provider capabilities. 

In a preferred embodiment, wireless web architecture 40 translates and transfers 
request messages via translator 41. The translator 41 translates the request message into 
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the standardized format, preferably an XML request, and forwards the translated request 
message to a selected content provider interface 50. Once a response message or an alert 
is generated by a content provider interface 50 or received from a third party content 
provider 60, the response message or alert is transformed by transformer 42 via selected 

5 transforms, i.e. XSL transforms, into device type specific, content type specific or other 
specific forms for the wireless devices 20. The message is then forwarded to proxy 
server and web applications 30 for communication to wireless devices 20. 

A method for spontaneously sending data to a device is also provided. As 
mentioned above, this is called sending an alert. In one embodiment, data and an 

10 identifier (ID) are sent to transformer 42. The data may come from either CPI 50 or a 
third party content provider 60. The ID may be one of a user ID, a device ID, a client ID, 
a customer ID or some other type of identifier. The ID is referenced in a database to 
associate it with a device. A format for presentation to the device is preferably 
determined and a style sheet is selected based on the device. The selected style sheet is 

15 then used to transform the data. After transformation, the transformed data is forwarded 
to the appropriate device 20. 

Fig. 5 depicts an example of a logical component model for handling 
asynchronous request messages/responses and alerts. Request messages can be passed to 
the architecture through a synchronous or asynchronous mechanism, originating in 

20 different forms (e.g., XML, Java objects, HTTP, etc.). The architecture can provide 
support for converting request messages into XML messages that are dispatched to 
specific third party content providers for processing. XML responses are then converted 
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back into an appropriate content type (XML, HDML, WML, HTML, etc.) and returned in 
the response. Again, XML is preferably the intermediate language of data exchange. 

In connection with fig. 5, fig. 6 illustrates a specific component model that may 
be used for handling synchronous requests. The individual components shown in figs. 5 
5 and 6 are discussed in more detail below. Although described below in a specific 
embodiment in connection with XML, the invention may be implemented with various 
other languages. 

In general, request messages, which may be generated by wireless devices, are 
communicated to a request transformer 130. The request will usually be in the form of an 

10 HTTP request. However, other types of messages can be used. The request transformer 
may communicate MIME information to a session manager 120, which in turn queries 
database 110 and receives session information. Request transformer 130 then processes 
the request messages and the session information to yield a flattened, basic XML stream, 
which is communicated to XML transformer 160. Here, "flat" is used in the sense that 

15 each form variable's corresponding XML tag is an immediate descendant of the 
document root. XML transformer 160 further processes the flattened, basic XML stream 
into an XML request message, which is communicated to dispatcher 200. Dispatcher 200 
selects a content provider interface 50 from a plurality of content provider interfaces. 
This is preferably done based on information retrieved from content provider map 

20 database 190 and information in the request message. Dispatcher 200 then forwards the 
XML request message to the selected content provider interface 50, which may further 
communicate with third party service 60 to generate a response message. 
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Upon receipt of an XML response message or alert from the third party content 
provider 60, content provider interface 50 forwards the response message or alert to 
dispatcher 200. Dispatcher 200 forwards the XML response message to XML transformer 
160. XML transformer 160 can transform the response message into a format for the 

5 device 20. XML transformer 160 queries XSL database 170 and DTD database 180. 
Based on the information retrieved, XML transformer 160 selects XSL transforms to be 
applied to the XML response message or alert in order to transform the XML response 
message or alert into the appropriate format. The processed XML response or alert is then 
forward to the response transformer 150. Response transformer 150 can query a Java 

10 bindings database 140, if necessary, and convert the processed XML response into the 
form expected by the wireless device, if conversion is necessary. 

In a preferred embodiment, inbound HTTP requests are received by a servlet 202, 
or some similar server-side construct, and then forwarded to the wireless web architecture 
for processing. An interface component, called the message controller 204, that can 

15 provide a simple application programming interface (API) for the application developer 
is also preferably provided. The message controller 204 can manage the synchronous 
block-and-wait nature of HTTP requests. Synchronous as used herein does not mean that 
messages transfers are clocked, but rather that there is a mechanism via the message 
controller that blocks any additional request messages for service while waiting for a 

20 response. Thus, the servlet 202 can forward HTTP request information to the message 
controller 204 and wait for a device-specific response to be formulated, which it then 
returns as the HTTP response. Also, the database objects that are shown and described 
do not necessarily imply that there will be more than one database. 
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The different components shown in Figs. 5 and 6 and their interaction will now be 
described in more detail. 

Message Controller 

5 The message controller 204 is preferably a wrapper around the internal 

components of the architecture for use in an HTTP context. The application developer 
will, in most cases, interface with this component, and will not necessarily have to 
interface directly with the other internal components of the framework. Figure 7 
illustrates an example of a message interface. 

10 In one embodiment, HTTP requests from wireless devices are translated into 

messages in a standardized format. This can be accomplished with the message 
controller. Various interfaces may be provided on the message controller to give greater 
control regarding this translation to the application developer. For example, Java Binding 
interfaces can be offered through the message controller 204. Java bindings, or classes 

15 representing a given XML entity, may be provided for each XML request message and 
response message that is part of the DTD for the given market domain. Bindings enable 
the application developer to employ a Java interface instead of working with the XML 
directly. Each class may implement accessor methods for the DTD elements that are 
associated with that object. For portability and interface abstraction, these bindings are 

20 preferably then wrapped inside a class (named MarketDomainBinding in Fig. 8). Every 
binding should implement a toXml() method that streams out its contents as an XML 
stream. Figure 8 diagrams an example of this interface. 
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A second method for creating messages from HTTP requests involves automated 
conversion techniques. In order to use this method, the application developer should 
appropriately name their HTTP form variables (querystring keys) according to the 
equivalent XPath specification of the DTD, and include hidden fields for the message 
5 key. The request transformer 130 should parse each of the form variables out of the 
querystring, along with its associated values, and place it into "flattened XML," 
eventually becoming a message. 

For example, in most cases the HTTP request will include a message key. As 
discussed above, the message key should include an action, i.e. a request for a stock 
10 quote. The form variable "action" is parsed out of the message. Based on the specified 
action, additional information may be required to form the message. In this example, a 
stock symbol is required for the stock quote request. The HTTP request can be parsed to 
find the addition information. This information and the form variables are then placed in 
the message. 

15 A third approach for creating messages from HTTP requests allows the 

application developer to provide XSL to transform a "flattened XML" request message. 
In this scenario, the application developer registers their XSL in the XSL database 170, to 
be used by the XML transformer 160. Once the HTTP request is received and "flattened" 
by the request transformer 130, for example, by the second approach described above, the 

20 XML transformer 160 may be invoked to transform the resulting XML into an 
appropriate form for the data. This approach offers greater flexibility than the automatic 
conversion. 
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Request Transformer 

The request transformer 130 can receive an incoming request object that should 
correspond to the initial HTTP request, and perhaps a Java or XML binding of the 
request. From these it can generate an XML stream. If a Java binding is received, the 

5 body of the stream is just the XML derivable from the binding. In the case where no 
binding is received, the stream includes a body, which is a "flattened" encoding of the 
HTTP request's form data. A standard procedure that may be used for writing form 
values to a simple "flat" XML document is for each tag to have the same name as a form 
variable and the tag's value is the value of the variable. In addition to form data, session 

10 data, MIME data, and message key information may be encoded in the stream. Figure 9 
illustrates an example of the request transformer interface. The resulting XML stream 
does not necessarily conform to a DTD accepted by a content provider's interface. In 
those cases, the XML transformer 160 (see below) may receive the stream and can 
transform it into an acceptable XML message request. 



1 5 Session Manager 

The session manager 120 should be responsible for identifying and returning state 
information about a given set of interactions between a client device (and its user) and the 
Web application server 30. The session manager can operate as an extractor to access 
system information about a browser of a particular device. In this context, "session" does 
20 not refer to the establishment of a secure connection (for example, SSL), but rather to a 
series of interactions between a client and server over a defined period. The following 
kinds of state-based information may be maintained for the duration of a session: 
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1. System state, or the information that must be maintained for the internal 
functions of the system, for example, the user agent (or browser), or the type 
of device originating the request. 

2. User-defined state, or the information that must be maintained for the front- 
5 end application programmer to successfully supply a smooth user interface 

(for example, hypertext history information, or a notion of the user's previous 
path, and the user's unique ID). 

3. Content provider state, or the information that must be maintained for the 
back-end information source, i.e. the content provider (for example, a session 

1 o token that the content provider needs to perform transactions on behalf of the 

user). 

When a request is made, the session manager 120 should first determine whether 
an ongoing session exists for the requesting client. If no session exists, the session 
manager 120 can create a new object to maintain the three kinds of state-based 

15 information mentioned above. Otherwise, if a session already exists, then the state 
information can be returned from a database 110. 

Certain variables of the system state can be configured with each application. As 
each new session is constructed, the session manager 120 automatically populates the 
system state with certain variables found in the HTTP header of the request. A system 

20 administrator should configure the application with the necessary information to extract 
the appropriate variables. The device type, user agent, and subscriber number are among 
typical variables that can be automatically extracted. 
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XML Transformer 

The XML transformer 160 can transform XML input into another form of XML 
output via XSL transformations. However, it is also possible to use the XML transformer 
to produce non-XML output, such as HDML or even plain-text. The XML transformer 

5 160 can receive inbound XML from the request transformer 130, transform it and pass 
the resulting request message to the dispatcher 200. The XML transformer 160 can also 
receive outbound response messages from the dispatcher 200, transform them into the 
correct format (e.g., HTML, HDML, WML) for the target device/user, and forward the 
result to the response transformer 150. Thus, XML transformer 160 is shown twice in 

10 Fig. 6. Figure 10 is an example of an object model of the XML transformer 160 and its 
associated objects. 

In the example shown in Fig. 10, The transformation is facilitated by an 
XMLProcessor, which may include an XmlParser and XslProcessor. The parser creates a 
Document Object Model (DOM), and supports a run time setting that can be used to 
15 validate XML against a DTD. The XSL processing component handles the actual 
transformation. 

The XML transformer 160 can receive a message, and find and apply the 
appropriate XSL for transforming the data contained within that message. The XSL 
source (for example, string, URI or file) is preferably retrieved through a database query 
20 to database 170, preferably taking into account the following items from the message and 
from session information: 

• Message Key i.e. {market domain, action, action type, content provider 
ID} 
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• User Agent (or browser type) of the device making the request 

• Type (or model) of device making the request 

• User ID 

These items affect how information should be displayed on a given device, and should be 
5 taken into account by the application developer when creating the application. A map 
cross referencing information in the message and style sheets should be created. The 
map can indicate which style sheets are to be used for certain types of messages. 

The following table helps to illustrate this point. The following table is an 
example of the information that may be stored in database 170. 



XSL Selection Map 


Market 
Domain 


Action 


Action 
Type 


Content 
Provider 


Device 
Type 


User Agent 


XSLJJRI 


Financia 
I 


RealTim 
eQuote 


Response 


XYZ 

Brokerag 
e 


3-line 
phone 


UP. Browser 

/3.1-UPG1 

UP.Link/3.2 


http://. .Jxsl_stylesheets/rt 
QuoteResp.xsl 


Financia 
I 


Delayed 
Quote 


Response 


XYZ 

Brokerag 
e 


3-line 
phone 


UP. Browser 

/3J-UPG1 

UP.Link/3.2 


http://. . Jxsl_stylesheets/d 
QuoteResp.xsl 


Financia 
I 


RealTim 
eQuote 


Response 


ABCInc 


Palm 


Mozilla /2. 0 


http:// . Jxsl_stylesheets/rt 
QuoteRespLxsl 



10 

Consider a response message with the following message key: {Financial, 
RealTimeQuote, Response, ABC Inc}, a device type of "Palm" which has a 
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"Mozilla/2.0" User Agent. A database query will be transacted to look for XSL in 
database 170 that matches the above information. The third row in the table matches the 
above description with the location, for example, an URL, for the appropriate XSL style 
sheet, namely "http ://... /xsl_stylesheets/rtQuoteRespl.xsl." 
5 In many cases, the XSL lookup and selection process will produce a single XSL style 
sheet. However, there may be situations where it is desirable that the lookup produce a 
collection of more than one XSL style sheet. When this occurs, there are a number of 
possible strategies for applying the multiple transformations to an XML source, 
including: 

10 • Sequential application, in which multiple sheets are applied in turn to an initial 

XML source (in a chained fashion), producing a single XML output 
• Independent application, in which multiple style sheets are applied independently 

to the same initial XML source, resulting in multiple XML outputs 
In the sequential strategy, multiple XSL style sheets are selected. Depending upon 
1 5 which style sheets are selected, the style sheets may be applied in a pre-selected order or 
the ordering may not be relevant. For example, the result of a first style sheet may be 
need for the application of a subsequent style sheet. After determining an order, each 
subsequent XSL style sheet is applied, in turn, to the result of the previous 
transformation. Thus, it is preferable that the result of each interim transformation be 
20 well-formed XML, so that it can serve as input to the next transformation. Figure 1 1 
depicts the sequential application of S.S.. The figure shows XML 0 , the initial XML 
source, being transformed into XML n via n distinct transformations. The i th 
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transformation is specified by XSL Stylesheet^ and the result of applying the i 
transformation is the XML output, XML 1 . 

One example of the utility of chaining sequential transformations involves content 
branding. "Raw" XML can be transformed into a presentation format appropriate for an 
5 application or device, for example, a specific browser, and then, as a second step, 
references to appropriate branding material, for example, logos, can be inserted. This 
facilitates separating branding from other presentation or stylistic concerns. In most 
cases, the branding step can just as easily be performed first, and the presentation format 
transformation applied second. Figure 12 illustrates this as XML is transformed into 

10 WML, by XSL stylesheeti in preparation for presentation on a WAP phone, for example, 
and then that WML is branded for a specific enterprise by XSL stylesheet 2 . 

A second multi-transformation strategy is depicted in Figures 13a and 13b. 
Multiple XSL stylesheets, XSL Stylesheetsi- XSL Stylesheets n are applied to source 
XML 0 . The application of each stylesheet results in separate XML output, XML 1 -XML n . 

15 Here there is no ordering or sequencing of the selected XSL style sheets. Each 
transformation is independent and can be applied simultaneously to a single XML source. 
An example of this strategy is the delivery of content, simultaneously as voice and text, 
to a single device. Figure 13b shows an example of this strategy using transformations 
by stylesheeti and stylesheet2 into VoiceXML and WML for voice and text presentation, 

20 respectively. The source XML is transferred by , XSL Stylesheetsi- XSL StylesheetS2 
into different output types. 

Sequential and independent multi-transformation strategies are not the only 
possibilities, nor are they mutually exclusive. They can be combined in a number of 
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ways, producing a variety of hybrid strategies. One example of a hybrid strategy is 
shown in Figure 14, in which one of n simultaneous transformations is comprised of a 
sequence of sub-transformations. Here, XSL Stylesheetsi- XSL Stylesheets n are applied 
simultaneously to source XML 0 , resulting in output XML 1 -XML n . Application of each 
5 of these style sheets should result in well-formed XML. Consequently, subsequent 
stylesheets may be applied to output XML 1 -XML n . In the example shown, stylesheet2b 
is sequentially applied to output XML 2a , resulting in output XML 2b . 

Response Transformer 

The response transformer 150 receives outbound XML messages, for example, 
10 from the message controller 204, and, if necessary, converts them into another form that 
is expected by the application servlet 202 or wireless device 20. If the servlet 202 
expects an XML stream, no conversion will occur. If the servlet expects a Java binding, 
the specific class for the binding will be retrieved from the database 140. The binding 
should be instantiated, populated with the data from the XML string and sent back 
1 5 through the message controller 204 to the servlet 202. Figure 1 5 illustrates an example of 
the response transformer / data manager interface. 

In one embodiment, the response transformer may also generate a combined 
response from a plurality of responses or alerts from one or more content providers. The 
plurality of responses may be generated from a plurality of requests. 

20 Dispatcher 

The dispatcher's 200 primary function is to dispatch incoming messages to an 
appropriate CPI 50, which, in turn, may communicate with a third party content provider 
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60. To do so the dispatcher 200 must first identify which CPI 50 can and should handle 
the request embedded within the incoming message, and, if necessary, load that CPI 50. 
This may be accomplished using a database lookup on information in the message key 
(for example, {market domain, action, action type, content provider id}). In a preferred 
5 embodiment only certain information, for example, market domain, need be specified for 
a database lookup to be attempted. Any or all of the other components of the message 
key can be "wildcarded" for the lookup. A wildcard stands for any values that might 
occur in the database for that component of the message key. The following table helps 
illustrate this point. 

10 



Content Provider Interface Map 


MarketDomain 


Action 


ActionType 


ContentProvider 


ContentProviderlnterface 


Financial 


RealTimeQuote 


Request 


XYZ Brokerage 


mojo.cpi.XyzBrokerageCPI 


Financial 


DelayedQuote 


Request 


XYZ Brokerage 


mojo.cpi.XyzBrokerageCPI 


Financial 


DelayedQuote 


Request 


JKL Financial 


moj o . cpi . JklFinancialCPI 


Financial 


RealTimeQuote 


Request 


ABC Inc 


mojo.cpi.AbcIncCPI 



Consider a request with an associated message key having the following values: 
(Financial, RealTimeQuote, *, *) 

This message key contains values for market domain and action, "Financial" and 
15 "RealTimeQuote," respectively, and wildcards in place of action type and content 
provider values. The CPI 50 found in each row of the table where the value of market 
domain is "Financial" and the value of action is "RealTimeQuote," namely 
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mojo.cpi.XyzBrokerageCPI and the mojo.cpi.AbcIncCPI, can service this request. In 
cases where more than one CPI can service a request, a round-robin is preferably used to 
determine which CPI to send the request. In comparison, more detailed a request with 
the message key (Financial, RealTimeQuote, *, XYZ Brokerage) can only be serviced by 
5 moj o . cpi .XyzBrokerageCPI . 

Content Provider Interfaces 

CPI 50 may be java classes that implement an abstract interface for processing 
messages that are forwarded from the dispatcher 200. Figure 16 illustrates an example of 
the CPI interface. The back-end application developer should provide CPI classes 

10 specific to that application. The CPI 50 may process the inbound message, and its 
contained XML request in any manner it sees fit, either through direct manipulation of an 
XML DOM tree, SAX, or through a java specific XML binding. If a developer chooses 
to use a bound Java class, an alternative to passing the CPI a direct XML stream is to 
pass and receive a bound Java instance. This shields the application developer from 

15 having to know anything about XML itself, and allows him to simply concern himself 
with the actual data model or message content. Inbound content provider session data 
may be made available to the CPI 50 through the incoming message. For outbound data, 
the CPI is preferably able to change the content provider session data if required, and 
insert the response XML into the market data portion of the outgoing message. 

20 

The above components can be combined into a system to provide a uniform 
approach to content delivery. Using this system, an application developer is able to 
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render their content in the appropriate format to a wide variety of devices, without having 
to customize the application for each type of device. 

The embodiments illustrated and discussed in this specification are 
intended only to teach those skilled in the art the best way known to the inventors to 

5 make and use the invention. Nothing in this specification should be considered as 
limiting the scope of the present invention. The above-described embodiments of the 
invention may be modified or varied, and elements added or omitted, without departing 
from the invention, as appreciated by those skilled in the art in light of the above 
teachings. It is therefore to be understood that, within the scope of the claims and their 

1 0 equivalents, the invention may be practiced otherwise than as specifically described. 
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Claims 

We Claim: 

1 . A system for deploying content to devices, comprising: 

a translator operative to receive data sent from devices, the translator operative to 
translate the data into a standardized format; 

a content provider interface operative to receive the data in the standardized 
format and to provide content data in the standardized format; and 

a transformer operative to receive the content data and to transform the content 
data into a format for a particular device. 

2. The system according to claim 1, wherein the standardized format is an XML 
message. 

3. The system according to claim 1, wherein the transformer is operative to select a 
transformation based on the pre-selected format and to transform the content data using 
the selected transformation. 

4. The system according to claim 3, wherein the transformation is selected from a 
group of XSL style sheets. 

5. The system according to claim 3, wherein the transformer is operative to select a 
plurality of transforms and to apply the plurality of transforms in at least one of: 
sequentially, independently, or a combination of both, to transform the content data. 

6. The system according to claim 1, further comprising an extractor operative to 
access session information about a browser of the particular device. 
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7. The system according to claim 1, further comprising a composer operative to 
generate a combined response to the particular device from a plurality of responses 
received to a plurality of requests provided to a plurality of content providers. 

8. The system according to claim 1, wherein the devices are wireless devices. 

9. A method of communicating with devices that use different communication 
schemes, comprising: 

receiving first data from one or more devices; 

translating the first data into a standardized format; 

providing the translated data to a content provider interface; 

receiving second data response from the content provider interface in the 
standardized format; 

transforming the second data into content type specific forms for the one or more 
devices; and 

forwarding the transformed second data to the one or more devices. 

1 0. The method according to claim 9, further comprising: 
extracting information about the device from the first data. 

11. The method according to claim 10, wherein the extracted information includes 
device specific features. 

12. The method according to claim 10, wherein the transforming step comprises: 
selecting an XSL style sheet based on the extracted information; and 

using the selected XSL style sheet to transform the second data. 

13. The method according to claim 10, wherein the extracted information includes 
information about a browser. 
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14. The method according to claim 10, wherein the extracted information includes a 
message key. 

15. The method according to claim 14, further comprising: 
selecting the content provider interface based on the message key. 

16. The method according to claim 14, wherein the message key includes at least one 
of: 

a vertical market; 

an action; 

an action type; and 

a content provider identifier (ID). 

17. The method according to claim 16, wherein the vertical market is a brokerage 
market, the action is a quote, the action type is at least one of a request and a response, 
and the content provider ID corresponds to a particular brokerage. 

18. The method according to claim 12, wherein at least two style sheets are selected 
and applied independently to the second data.. 

19. The method according to claim 12, wherein at least two style sheets are selected 
and applied to transform the second data 

20. The method according to claim 19, wherein the style sheets are applied 
sequentially. 

21 . The method according to claim 19, wherein an order of applying the style sheets 
is pre-selected. 

22. The method according to claim 19, wherein at least three style sheets are applied 
both independently and sequentially. 
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23. The method according to claim 9, wherein the first data is a request. 

24. The method according to claim 23, wherein the request is an hyper-text transfer 
protocol (HTTP) request. 

25. The method according to claim 9, wherein the second data is a response. 

26. The method according to claim 9, wherein the standardized format of the second 
data is an XML message format. 

27. The method according to claim 9, wherein the content provider is a third party. 

28. The method according to claim 9, further comprising: 

querying a provider database if the content provider is a new content provider; 

and 

receiving a previously registered XSL style sheet associated with said new 
content provider from the provider database. 

29. The method according to claim 9, wherein the providing step includes providing 
the translated data to more than one of the content providers, and further comprising: 

composing a combined set using the second data of the more than one content 
providers. 

30. The method according to claim 9, wherein said device is a wireless device. 

31. A method for spontaneously sending data to a device, comprising: 
sending data and an identifier (ID) to a transformer; 

looking up the ID in a database to associate it with a device; 
selecting a style sheet based on the device; 

transforming the data using the selected style sheet into transformed data; and 
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forwarding the transformed data to the device. 

32. The method according to claim 3 1 , wherein the ID includes at least one of: 
a device ID; 

a user ID; 

a client ID; and 

a customer ID. 

33. The method according to claim 31, wherein the database includes information 
about a browser. 

34. The method according to claim 3 1 , wherein the data includes information about a 
message key. 

35. The method according to claim 3 1 , wherein the message key includes at least one 
of: 

a vertical market; 

an action; 

an action type; and 

a content provider identifier (ID). 

36. The method according to claim 35, wherein the vertical market is a brokerage 
market, the action is a threshold alert, the action type is a push, and the content provider 
ID corresponds to a particular brokerage. 

37. The method according to claim 33, wherein at least two style sheets are selected 
and applied to transform the data. 

38. The method according to claim 32, wherein the style sheets are applied at least 
one of: sequentially, independently and a combination of both. 
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39. The method according to claim 32, wherein an order of applying the style sheets 
is pre-selected. 

40. The method according to claim 38 wherein the independent application is 
simultaneous. 

41 . The method according to claim 32, wherein the content provider is a third party 
service. 

42. The method according to claim 32, further comprising; 

querying a provider database if the content provider is a new content provider; 

and 

receiving a previously registered XSL style sheet associated with said new 
content provider from the provider database. 

43. The method according to claim 32, wherein said device is a wireless device. 

44. A method for deploying markup content to browser applications comprising the 
following steps: 

accepting inbound data; 

transforming said inbound data into XML messages; 
selecting a content provider interface; 

forwarding said XML messages to the selected content provider interface; 

receiving an XML message response from the content provider interface; 
selecting at least one XSL style sheet from a group of XSL style sheets; 

transforming said XML message response into outbound data using said at least 
one selected XSL style sheet; and 

forwarding said outbound data to the browser application. 

45. The method according to claim 44, further comprising: 
extracting session information from said inbound request. 
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46. The method according to claim 44, further comprising: 
transmitting said XML messages to a content provider. 

47. The method according to claim 44, wherein said selecting step comprises: 
selecting said content provider interface from a group of content provider 

interfaces based on a unique message key. 

48. A method for deploying markup content to browser applications on devices, 
comprising: 

accepting requests from devices; 

processing said requests as synchronous messages via a block and wait 
mechanism; 

retrieving information related to at least one of form data, session data, MIME 
data, and a message key in order to generate an XML stream; 
parsing said XML stream into an XML message; 

determining all content provider interfaces that can handle said XML message 
based on said message key; 

selecting a content provider interface to process said XML message; 
forwarding said XML message to said selected content provider interface; 
receiving a response from said selected content provider interface; 
selecting one or more XSL style sheets; 

transforming said response into one or more forms using said selected XSL style 
sheets; and 

forwarding said transformed response to said devices. 

49. The method according to claim 48, further comprising the steps of: 

creating a DOM; and 

setting a runtime parameter to validate XML against a document type 
definition (DTD). 
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50. 



The method according to claim 48, wherein said device is a wireless device. 



5 1 . The method according to claim 48 wherein at least two XSL style sheets are 
selected and further comprising applying the style sheets at least one of sequentially and 
independently. 

52. The method according to claim 5 1 wherein the independent application is done 
simultaneously. 

53. The method according to claim 51 wherein an order of applying the XSL style 
sheets is pre-selected. 

54. The method according to claim 48 wherein at least three XSL style sheets are 
selected and applying the style sheets at least one of sequentially, independently, and a 
combination of both. 

55. The method according to claim 54 wherein the independent application is done 
simultaneously. 

56. A method of communicating from a device to a controller using different 
communication schemes, comprising: 

sending first data from one or more devices using one or more 
transmission formats to a controller; and 

receiving from the controller second data using content specific forms for said one 
or more devices, wherein the first data is translated by the controller into a standardized 
format and conveyed to a content provider, and the second data is received by the 
controller from the content provider in the standardized format and is transformed by the 
controller into said content specific forms for the one or more devices. 

57. A method of transforming data, comprising: 
receiving a message; 
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extracting information from the message; 

selecting transformation specifications based on the extracted information; and 
applying the selected transformation specifications to the data. 

58. The method of claim 57, further comprising retrieving the transformation 
specifications from a database. 

59. The method of claim 57, further comprising cross-referencing the transformation 
specifications in the database to the extracted information. 

60. The method of claim 57, wherein the message includes a message key. 

61 . The method according to claim 60 wherein the message key includes at least one 
of: 

a vertical market; 

an action; 

an action type; and 

a content provider identifier (ID). 

62. The method of claim 57, wherein the message comprises session information 
including at least one of a user agent and a device type. 

63. The method of claim 57, wherein the transformation specifications are specified 
as XSL style sheets. 

64. The method of claim 63, wherein a single XSL style sheet is selected. 

65. The method of claim 63, wherein multiple XSL style sheets are selected. 

66. The method of claim 57, wherein the message is an XML message. 
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67. A method for applying multiple transformations to data, comprising: 
selecting a plurality of transformation specifications based on information about 

the data; and 

sequentially applying the transformation specifications to the data. 

68. The method of claim 67, wherein a result of each interim transformation is well- 
formed XML. 

69. The method of claim 67, wherein an order of applying the transformation 
specifications is pre-selected. 

70. The method of claim 67, wherein the data is an XML message. 

71. The method of claim 67, wherein the transformation specification is an XSL style 
sheet. 

72. A method for applying multiple transformations to data, comprising: 

selecting plurality of transformation specifications based on information about the 
data; and 

independently applying the transformation specifications to the data, resulting in 
more than one output. 

73. The method of claim 72, further comprising applying another transformation 
specification either before or after the independent application of the plurality of 
transformation specifications. 

74. The method of claim 72 wherein the independent application is simultaneous. 

75. In a content delivery system including a translator receiving data sent from 
devices and translating the data into a message, a method for converting the data into the 
message, the method comprising: 
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creating java bindings for each message in a document type definition; 

wrapping the java bindings in a class; and 

calling a method on the class to create the message. 

76. The method of claim 75 , wherein the message is an XML message. 

77. A method of converting an HTTP request into a message, comprising: 
receiving the HTTP request; 

extracting form variables needed for the message from the HTTP request; 
forming the message including the extracted form variables. 

78. The method of claim 77 wherein the HTTP request includes a message key. 

79. The method of claim 78, further comprising: 
determining an action from the message key; and 
determining the form variables associated with the action. 

80. The method of claim 77 wherein the message is an XML message. 

8 1 . The method of claim 80 wherein XSL style sheets transform the form variables 
from the XML message. 

82. The method of claim 81 wherein the XSL is registered in a database. 

83. A system for converting HTTP requests into a standard message format, 
comprising: 

a message controller receiving the HTTP request; and 

a request transformer to parse form variables out of the HTTP request to generate 
an XML stream. 

84. The system of claim 83, further comprising: 
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at least one database; 

an XML transformer to parse the XML stream into an output stream and to 
transform the XML stream using XSL transforms by retrieving information from the at 
least one database based on specifications in the HTTP request. 

85. The system of claim 84 wherein the XSL transforms are registered in the 
database. 
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Abstract of the Disclosure 



A method and system for deploying content to devices is provided. The method 
and system can be used to deploy markup content to web browser applications on 
wireless devices. The wireless devices may included, for example, WAP phones, HDML 
phones, Palm VII, Palm V, etc. The method and system can also be used in conjunction 
with wired systems. A translator receives data, in a variety of formats, from the wireless 
devices. The translator then translates the data into a standardized format. A content 
provider interface receives the data in the standardized format and provides content data, 
also in the standardized format. The content data in the standardized format is provided 
to a transformer. The transformer transforms the content data into the pre-selected format 
for the particular wireless device. The content data can then be utilized and manipulated 
by the wireless device. 
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